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PROCEDE D'ACCES A UN OBJET A L'AIDE D'UN NAVIGATEUR DE TYPE 
"WEB" COOPERANT AVEC UNE CARTE A PUCE ET ARCHITECTURE 
POUR LA MISE EN CEUVRE DU PROCEDE. 

L'invention concerne un proc6de tfacces a un objet a I'aide d'un navigateur de 
type "WEB" cooperant avec une carte & puce, plus particulierement d'accts a 
un objet qui sera appel§ virtuel ci-apres. 

L'invention concerne plus particulierement encore un proc£d6 d'acc&s 
securist aux objets pn§cit6s. 

L'invention concerne §galement une architecture de mise en oeuvre d'un tel 
proc6d6. 

Le navigateur "WEB" est cornpris dans une station d'utilisateur. Cette station 
d'utilisateur est connectee & un reseau de transmission de donntes, et 
notamment de type Internet. 

Dans le cadre de l'invention, le terme "objet" dojt etre considere dans son sens 
le plus general. II englobe de nombreux types de ressources informatiques, tels 
que des fichiers textes, des fichiers images ou des fichiers multim§dias (video, 
son, etc.). II englobe 6galement des transactions ou des connexions a un 
systfeme informatique, selon un protocole donn6. 

Dans le premier cas, on parlera ci-apr6s d'objets statiques, car leur instance 
ne depend pas du temps. Dans le second cas, on parlera d'objets dynamiques, 
car leur instance varie en fonction du temps. On peut citer, & titre d'exemple 
non limitatif, dans le cadre d'un reseau de type Internet, une connexion de type 
'Telnet". 

Toujours dans le cadre de l'invention, le terme "station d'utilisateur" 
doit etre cornpris dans un sens general. La station d'utilisateur precitee peut 
§tre notamment constitute par un ordinateur personnel fonctionnant sous 
divers systemes d'exploitation, tels WINDOWS ou UNIX (tous deux etant des 
marques deposees). Elle peut etre aussi constitute par une station de travail, 
un ordinateur portable ou un terminal de carte, dit d<§di§. 



De m§me, dans le cadre de I'invention, le terme "reseau Internet" englobe, 
outre le reseau Internet proprement dit, les reseaux prives d'entreprises ou 
slmilaires, du type dit "intranet", et les reseaux les prolongeant vers FextSrieur, 
du type dit "extranet", de fa$on generate tout reseau dans lequel les ^changes 
de donnees s'effectuent selon un protocole du type Internet. 
Dans ce qui suit, sans en limiter en quoi que ce soit la portde, on se placera 
dans le cadre de 1'application prSferee de r invention, sauf mention contraire. 
On considSrera done une station d'utilisateur, que Ton appellera simplement 
"terminal", munie d'un lecteur de carte £ puce et connecte d un r6seau de type 
Internet 

Un systdme d'application a base de carte a puce comporte g6n§ralement les 
elements principaux suivants : 
une carte a puce ; 

un systdme hote constituant le terminal precit§ ; 

un reseau de communication, v a savoir le reseau Internet dans 
rapplication pref6r6e ; 

et un serveur d'application connects au reseau. 
La figure 1A i I lustre schematiquement un exemple d'architecture de ce type. 
Le terminal 1 , par exemple un ordinateur individuel, comporte un lecteur 3 de 
carte d puce 2. Ce lecteur 3 peut etre ou non physiquement int§gr6 dans le 
terminal 1. La carte a puce 2 comporte un circuit integre 20 dont des 
connexions d'entrees-sorties affleurent en surface de son support pour 
autoriser une alimentation en energie electrique et des communications avec le 
terminal 1. Ce dernier comprend des circuits d'acces a un reseau de 
transmissions de donnees Rl. Ces circuits dependent, notamment, de la nature 
du reseau Rl et du terminal!. A titre d'exempleHI peuit^s'agir d'une carte 
reseau pour un r§seau de type local ou d'un modem pour se connecter d une 
ligne t6lephonique commutee ou a un reseau numerique a integration de 
services ("RNIS"), pour se connecter au reseau Internet, par exemple via un 
prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la 
terminologie anglo-saxonne). 



Le terminal 1 comprend naturellement tous les circuits et organes necessaires 
& son bon fonctionnement, et qui n'ont pas ete represents dans un but de 
simplification du dessin : unit§ centrale, m6moires vive et fixe, m§moire de 
masse d disque magn6tique, lecteur de disquette et/ou de C6d§Rom, etc. 
Habituellement, le terminal 1 est aussi reli6 a des periph<§riques classiques, 
int6gr6s ou non, tels un §cran de visualisation 5 et un clavier 6. 
Le terminal 1 peut etre mis en communication avec des serveurs ou tous 
systdmes informatiques connectes au reseau Rl t dont un seul, 4, est illustr6 sur 
la figure 1A. Dans le cas de I'application preferee de I'invention, les circuits 
d'acces 1 1 mettent le terminal 1 en communication avec les serveurs 4 grace d 
un logiciel particulier 10, appel§ navigateur de type "WEB" ou "browser" selon 
la terminologie anglo-saxonne. Celui-ci permet d'acceder a diverses 
applications r§parties sur Tensemble du reseau R/, g6n6ralement selon un 
mode "client-serveur". 

Habituellement, les communications sur les r6seaux s'effectuent 
conform6ment S des protocoles repondant a des standards comprenant 
plusieurs couches logicielles superposees. Dans le cas d'un reseau Rl de type 
Internet, les communications s'effectuent selon des protocoles specifiques § ce 
type de communications, qui seront detailles ci-apr£s, mais qui comprennent 
§galement plusieurs couches logicielles. Le protocole de communication est 
choisi en fonction de I'application plus particuli§rement vis6e : interrogation de 
pages "WEB", transferts de fichiers, courrier electronique (e-mel, ou "e-mail" 
selon la terminologie anglo-saxonne), forums ou nouvelles ("news" selon la 
terminologie anglo-saxonne), etc. 

L'architecture logique du systeme comprenant un terminal, un lecteur de carte 
£ puce et la carte d puce, est representee schematiquement par la figure 1B. 
Elle est d6crite par la norme ISO 7816, qui elle-meme comportent plusieurs 
sous-ensembles : 

ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et le marquage 
des cartes ; 



ISO 7816-3, en ce qui concerne le transfer! de donnees entre le terminal 
et la carte a puce ; et 

ISO 7816-4, en ce qui concerne la structure du jeu d'ordres et le format 
des commandes. 

Sur la figure 1B, du cote terminal 1, on n'a repr§sent6 que les couches 
r6pondant a la norme ISO 7816-3, referencees 101, et le gestionnaire d'ordres 
"APDU" (norme ISO 7816-4), reference 102. Du c&te carte d puce 2, les 
couches repondant a la norme ISO 7816-3 sont r§ferenc6es 200 et le 
gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est reference 201. Les 
applications sont referencees Ai, A§\ .... An ; n etant le nombre maximum 
^applications pr§sentes sur la carte a puce 2. 

Une application "cardlet", Au presente dans la carte a puce 2 (figure 1 A), 
dialogue avec le terminal 1 au moyen d'un jeu d'ordres. Ce jeu presente 
typiquement des ordres d'ecriture et des ordres de lecture. Le format des 
ordres est connu sous rabreviation anglo-saxonne . de "APDU" (pour 
"Application Protocol Data Unit"). II est d6fini par la norme ISO 7816-4 pr§cit6e. 
Un "APDU" de commande est note "APDU. command* et un "APDU" de 
reponse est note " APDU '.response". Les "APDU" sont echanges entre le lecteur 
de carte et la carte a puce au moyen d'un protocole sp6cifi6 par la norme ISO 
7816-3 precitee (par exemple en mode caractere : T=0 ; ou en mode bloc : 
T=1). 

Lorsque la carte a puce 2 inclut plusieurs applications distinctes, comrne 
illustr§ sur la figure 1B, on parle de carte multi-applicative. Cependant, le 
terminal 1 dialogue avec une seule application a la fois. Une application A\ se 
pr6sente, par exemple, sous la forme d'une piece de logicielle^dite "applet", eh 
langage "JAVA" (marque deposee), que Ton appellera ci-apres "cardlet". La 
selection d'un "cardlet" particulier A\ est obtenu a I'aide d'un "APDU" du type 
selection ("SELECT"). Une fois ce choix effectu§, les "APDU" qui le suivent 
sont achemines vers ce "cardlet". Un "APDU SELECT" nouveau a pour effet 
d'abandonner I'application en cours et d'en choisir une autre. Le sous- 
ensemble logiciel gestionnaire des "APDU" 201 permet de choisir une 



application particuliere A\ dans la carte a puce 2, de memoriser I'application 
ainsi choisie, et de transmettre et/ou recevoir des "APDU" vers et depuis cette 
application. 

En resume de ce qui vient d'etre decrit, la selection d'une application Aj et le 
dialogue avec celle-ci s'effectue par echanges d'ordres "APDU". On suppose 
que les applications Ai sont des applications conventionnelles, que Ton 
appellera ci-apres "GCA" (pour "Generic Card Application" ou application de 
carte g6n6rique). 

Dans un syst£me ^applications a base de carte a puce, comme illustr6 par 
I'architecture de la figure 1B, cette derniere peut se voir devolu diverses 
fonctions, notamment des fonctions de securit6. II est en effet avantageux de 
stacker les donn§es liees & la security (mots de passe, droits d'accfes, etc.) 
dans une carte d puce qui peut etre conservee par Tutilisateur. En outre les 
donnees 6tant enregistr§es dans une memoire fixe, sous une forme qui peut 
etre chiffr£e, elles ne sont pas facilement modifiables, ni mfeme directement 
lisibles de Text^rieur. 

Cependant, il est § noter que la carte 3 ne peut communiquer directement 
avec les navigateurs du commerce, sauf a modifier le code de ces demiers. 
Les cartes £ puce actuelles, qui par ailleurs sont conformes aux standards 
rappel6s ci-dessus, ont une configuration materielle et logicielle qui ne permet 
pas non plus de communiquer directement avec le r6seau Internet. En 
particulier, elles ne peuvent recevoir et transmettre des paquets de donn6es, 
selon Tun ou I'autre des protocoles utilises sur ce type de r^seau. II est done 
n6cessaire de pr6voir une pi6ce de logiciel additionnelle, implant§e dans le 
terminal 1 , g6n§ralement sous la forme de ce qui est appel6 un "plugnn", selon 
la terminologie anglo-saxonne. Cette pi£ce de logiciel, qui porte la r§f6rence 
12 sur la figure 1A, effectue Tinterface entre le navigateur 10 et la carte 2, plus 
precis6ment les circuits 6lectroniques 20 de cette carte 2. 
Dans I'etat actuel de la technique, le systeme bote associe au lecteur de carte 
3, e'est-^-dire le terminal 1, est associ§ §galement & une application 
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particulars. En d'autres termes, il est necessaire de prevoir un terminal 
specifique, dit "dedie", pour chaque application particuliere. 
En outre, il est clair que, meme compte tenu de la rapide evolution passee des 
technologies et de leur evolution future previsible, la capacite d'enregistrement 
d'informations dans des circuits de memoire, vive ou fixe, d'une carte a puce 
reste et restera tres limitee, si on compare cette capacite a celle offerte par un 
terminal "h6te" de cette carte a puce, et naturellement a celles offertes par des 
systemes plus importants, "mini-ordinateurs" ou grands systemes de type dit 
"main frame". Aussi, il n'est pas possible de stacker les donnees d'un nombre 
important ^applications dans une carte a puce, et notamment des fichiers de 
type multimedia tres volumineux. 

L'invention vise a pallier les inconvenients des dispositifs de Tart connu et dont 
certains viennent d'etre rappeles, tout en repondant aux besoins qui se font 
sentir. II doit notamment etre possible d'acceder a un grand nombre 
d'applications, meme volumineuses d'un point de -vue quantite de donnees, de 
natures diverses et reparties sur tout le reseau Internet. En outre, dans un 
mode de realisation prefere, les acces doivent beneficier d'une securite 
maximale, c'est-a-dire dans la pratique s'effeetuer via et sous le contrdle d'une 
carte a puce contenant toutes les donnees necessaires a la securisation des 
echanges de donnees. Enfin, ces acces doivent pouvoir s'effeetuer a partir d'un 
navigateur du commerce et etre transparents pour un utilisateur, qui ne doit 
"voir" que la carte a puce comme unique interlocuteur, quel que soit le lieu de 
stockage de ('application. 

Selon une premiere caracteristique importante du procede, la carte a puce 
presente au systeme h6te, c'est-a-dire le terminal, un modele de terminal 
virtuel. par exemple sous la forme d'une page en langage "HTML" (pour 
"HyperText Markup Language"), ou plus generalement en langage hypertexte, 
ou encore sous la forme d'un "applet^ en langage"JAVA" (marque deposee), 
ce qui permet a I'utilisateur de choisir une application particuliere parmi celles 
disponibles et proposees par la carte a puce. De ce fait, le terminal se trouve 
done banalise et supporte une pluralite d'applications. Le systeme h6te est vu 



comme un p6riph6rique de la carte a puce, et il met d sa disposition des 
ressources mat§rielles, tels un 6cran de visualisation, un clavier, etc. 
Pour ce faire, on pr6voit une couche de logiciel de communication specifique 
dans la carte d puce et son pendant dans le terminal. Le terme "specifique" doit 
fetre entendu comme specifique au proced6 de I'invention. En effet, ces 
couches de communications, dites sp6cifiques, sont banalis6es quelle que soit 
Tapplication consider§e. Elles n'interviennent que dans le processus d'echange 
de donn£es bidirecttonnel entre la carte d puce et le terminal, d'une part, et la 
carte d puce et le reseau. 

Les couches logicielles de communication sp6cifiques comprennent 
notamment des composants logiciels, dits "agents intelligents", permettant en 
particulier des conversions de protocoles. II existe des agents intelligents 
appareill§s dans les couches de communication specifiques respectives 
associ§es au terminal et a la carte & puce. Selon le proced6 de I'invention, il 
s'etablit des sessions entre agents intelligents appareilles. 

Selon une deuxteme caracteristique importante, le proc6d§ de I'invention rend 
possible I'activation ^'applications de type conventionnel, c'est-S-dire du type 
"CGA" pr6cit§, localises dans une carte £ puce, sans devoir les modifier en 
quoi que ce soit. 

Pour ce faire, on pr6voit un ou plusieurs agents intelligents dits 
traducteurs de script, qui regoivent des requites d'un navigateur et les 
traduisent en ordres "APDU" comprehensibles par Tapplication de type "CGA". 
Cette caracteristique technique permet d'implanter dans une carte d puce, dont 
1'architecture est conforme au procede de I'invention, un mecanisrne similaire d 
la fonction dite "CGI" (pour "Common Gateway Interface") implantee dans les 
serveurs "WEB" classique. 

Enfin, selon Tune des caracteristiques les plus importantes du proced6 
de I'invention, en mettant en oeuvre les fonctions et m6canisrnes precit6s, 
celui-ci permet d'acceder a des ressources informatiques reparties sur un 
reseau de transmission de donnees auquel est connecte le terminal, 
notamment le reseau Internet ou un reseau de type equivalent (intranet, 



8 



extranet), sans que I'utilisateur ait a se soucier de leurs emplacements. Dans 
ce qui suit, comme il a ete indique, ces ressources seront appelges "objets 
virtuels", statiques ou dynamiques. 

Pour ce faire, il est mis en oeuvre un agent intelligent traducteur de 
script dedie £ cette tache, cooperant avec les autres agents intelligents 
presents dans le terminal et/ou la carte a puce. Cet agent permet de ddfinir les 
objets virtuels auxquels la carte a puce peut acceder, et de ce fait 6galement 
I'utilisateur (ou porteur de la carte d puce), d'une part, et fournit au navigateur 
interrogates, via la carte a puce, des methodes permettant d'acc6der & ces 
objets virtuels d'autre part. 

L'invention a done pour objet principal un procede pour acceder d un objet 
localise dans un systeme informatique connects & un r6seau de type Internet 
par I'interm6diaire d'un navigateur de type "WEB", ledit navigateur §tant 
compris dans un terminal, muni d'un lecteur de carte £ puce et connects audit 
r6seau de type Internet, caracterise en ce qu'il comprend au moins les phases 
suivantes : 

a/ une premiere phase preliminaire consistant & implanter, dans ladite carte 
& puce, une premiere pidce de logiciel, constituant une couche protocolaire de 
communication specifique ; 

b/ une deuxfeme phase preliminaire consistant a implanter, dans ledit 
terminal, une seconde pidce de logiciel, constituant une couche protocolaire de 
communication specifique et formant interface avec au moins ledit navigateur 
"WEB"; 

- en ce que lesdites premiere et seconde pieces de logiciel specifique 
comprennent -en outre au moins une paire de premieres entites logiciel les 
appariees, chacune desdites entites cooperant I'une avec Tautre de maniere £ 
permettre I'etablissement d'une session d'echanges de donn6es bidirectionnels 
entre ledit terminal et ladite carte a puce, de maniere £ ce que ladite carte £ 
puce offre la fonctionnalitfe d'un serveur "WEB" ; 

en ce qu'il est procede a une troisieme phase preliminaire consistant en 
I'implantation dans ladite carte a puce d'un systeme de gestion de fichiers dit 
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virtuel, organise en repertoires, sous-repertoires et fichiers elementaires, une 
partie au moins desdits fichiers elementaires etant constitues par des fichiers 
elementaires dits virtuels associes chacun a Tun desdits objets et contenant 
des donnees de description permettant au moins de localiser celui-ci et de 
generer des donnees de methode d'acces ; 

en ce qu'il comprend une quatrieme phase preliminaire consistant a 
implanter d'au moins une deuxieme entite logicielle, apte a interpreter une suite 
constructions et a la traduire en une suite d'ordres, de maniere a cooperer avec 
ledit systeme de gestion de fichiers virtuel et ladite seconde piece de logiciel 
spec'rfique ; 

et en ce qu'il comprend au moins les gtapes suivantes : 
1/ etablissement d'une session d'echanges de donnees entre ledit terminal 
et ladite carte a puce, par I'intermediaire d'une desdites paires de premieres 
entites logicielles appariees, de maniere a transmettre une requete destinee a 
ladite deuxieme entite logicielle cooperant avec ledit systeme de gestion de 
fichiers dit virtuel ; 

21 elaboration et transmission audit navigateur "WEB", par I'intermediaire de 
ladite deuxieme entite logicielle, et via lesdites premiere et seconde pieces de 
logiciel, formant lesdites couches protocolaires de communication specifiques, 
d'une reponse a ladite requete comprenant une liste desdits objets accessibles 
via ladite carte a puce ; 

3/ selection par ledit navigateur "WEB" d'un desdits objets accessibles et 
envoi a ladite deuxieme entite logicielle d'une requete supplemental pour 
obtenir une instance de celui-ci dans ledit terminal ; 

4/ generation par cette ladite entit6 logicielle desdites donnees de methode 
d'acces, en fonction desdites donnees de description ; et 
5/ recherche dudit objet par utilisation desdites donnees de localisation et 
de methode d'acces, et creation d'une instance de cet objet dans ledit terminal. 
L'invention a encore pour objet une architecture pour la mise en ceuvre de ce 
procede. 
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L'invention va maintenant etre decrite de fagon plus detainee en se r§ferant 
aux dessins annexes, parmi lesquels : 

les figures 1A et 1B illustrent schematiquement ies architectures 
mat6rielles et logiques, respectivement, d'un exemple de systeme ^application 
d base de carte a puce selon Tart connu ; 

la figure 2 illustre schematiquement un exemple de systeme ^application 
d base de carte & puce selon l'invention, cette dernfere agissant en tant que 
serveur "WEB" ; 

la figure 3 illustre de fa?on simplifiee ('architecture logique d'un systeme 
dans lequel la carte £ puce comprend des agents intelligents ; 

la figure 4 illustre une architecture de systeme conforme a l'invention, 
dans laquelle la carte & puce comprend des agents intelligents traducteurs de 
scripts ; 

la figure 5 est un diagramme illustrant schematiquement les principales 
phase d'6changes entre un navigateur et une carte A puce presentant 
('architecture de la figure 4 ; 

la figure 6 est un diagramme illustrant schematiquement un aspect 
essentiel du proc6d6 selon l'invention par lequel il est possible d'acc£der £ des 
objets virtuels repartis sur un reseau de type Internet via une carte £ puce et un 
navigateur de type "WEB" ; 

la figure 7 illustre schematiquement Torganisation d'un systdme de 
gestion de fichiers dit virtuel pour la mise en ceuvre de cet aspect du proced6 
de l'invention ; 

la figure 8 est un exemple d'architecture comprenant un systdme de 
gestion de fichier virtuel selon la figure 7 ; 

les figures 9 a 15 sont des diagrammes illustrant schematiquement 
plusieurs mode de realisation du precede selon l'invention. 
Avant de d6crire le procede d'activation ^applications localisees dans une 
carte £ puce selon l'invention et de detainer une architecture pour sa mise en 
ceuvre, il apparalt tout d'abord utile de rappeler bri6vement les caracteristiques 
principales des protocoles de communication sur les r£seaux. 



L'architecture des r§seaux de communication est decrite par diverses 
couches. A titre d'exemple, le standard "OSI" ("Open System Interconnection 1 '), 
d6fini par I' "ISO", comporte sept couches qui vont des couches dites basses 
(par exemple la couche dite "physique" qui concerne le support de 
transmission physique) aux couches dites hautes (par exemple la couche dite 
d 1 "application"), en passant par des couches intermediates, notamment la 
couche dite de "transport". Une couche donn<§e offre ses services d la couche 
qui lui est immediatement superieure et requiert de la couche qui lui 
immediatement inf6rieure d'autres services, via des interfaces appropriees. Les 
couches communiquent d I'aide de primitives. Elles peuvent egalement 
communiquer avec des couches de m§me niveau. Dans certaines 
architectures, Tune ou I'autre de ces couches peut §tre inexistante. 
Dans un environnement de type Internet, les couches sont au nombre de cinq, 
et de fa^on plus precise, en allant de la couche superieure d la couche 
inf6rieure : la couche ^application ("http", 'ftp", "e-mail", etc.), la couche de 
transport ('TCP"), la couche d'adressage de reseau ("IP"), la couche de liens 
de donn6es ("PPP", "Slip", etc.) et la couche physique. 

Ces rappels etant effectu6s, on va maintenant decrire une architecture de 
systeme d'application a base de carte a puce autorisant celle-ci & agir comme 
un serveur "WEB". Un exemple d'une telle architecture est represents 
sch6matiquement sur la figure 2. Les elements communs aux figures 1A et 1B 
portent les memes references et ne seront re-decrits qu'en tant que de besoin. 
Pour simplifier le dessin, on n'a pas represents les divers p6riph6riques 
connects au terminal (figure 1 A : £cran 5 et clavier 6, par exemple). 
A I'exception de couches logicielles de protocole de communication 
sp6cifiques, r6ferenc6es 13 et 23a, respectivement implantees dans le terminal 
1 et la carte a puce 2a, les autres elements, mat6riels ou logiciels, sont 
communs § Tart connu. 

Le terminal 1 comprend des circuits 1 1 d'acces au r£seau R/, constitu6s par 
exemple d'un modem pour le reseau Internet ou d'une carte reseau pour un 
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reseau local. Ces circuits regroupent les couches logicielles inferieures Cl et 
C2, correspondant aux couches "physique" et de "lien de donnees". 
On a egalement represents les, couches superieures -C3, et C4,- correspondant 
aux couches "cfadressage de reseau" ("IP", dans le cas d'lntemet) et de 
"transport" ('TCP"). La couche superieure ^application ("http", "ftp", "e-mail", 
etc.) n'a pas ete representee. 

L'interface entre les couches inferieures, C1 et C2, et les couches 
superieures, C3 et C4, est constitute par une couche logicielle generalement 
appelee "driver couches basses". Les couches superieures, C3 et C4, 
s'appuient sur cette interface et sont mises en oeuvre par I'intermediaire de 
bibliotheques de fonctions specifiques ou bibliotheques reseau 14, avec 
lesquelles ellescorrespondent. Dans le cas du reseau Internet, "TCP/IP" est 
mis en oeuvre au moyen de bibliotheques dites de "sockets". 
Cette organisation permet a un navigateur 10 (figure 1 A) de poser des 
requites vers un serveur,4 (figure 1 A), pour la consultation de pages "WEB" 
(protocole "HTTP"), pour le transfer* de fichiers (pr©toeole4!FTP") ou I'envoi de 
courrier electronique (protocole "e-mail"), ce de facon tout a fait classique. 
Le terminal 1 comprend egalement un lecteur de carte 3, integre ou non. Pour 
communiquer avec la carte a puce 2a, le lecteur de carte englobe egalement 
deux couches basses, CC1 (couche physique) et CC2 (couche de lien de 
donnees), jouant un role similaire aux couches C1 et C2. Les interfaces 
logicielles avec les couches CC1 et CC2 sont decrites, par exemple, par la 
specification "PC/SC" ("part 6, service provider"). Les couches elles-memes, 
CC1 et CC2, sont notamment decrites par les normes IS© 7816-1 a 7816-4, 
comme il a ete^appele, 

Une couche logicielle supplementaire 16 forme interfaee entre les couches 
applicatives (non representees) et les couches inferieures, CC1 et CC2- La 
fonction principale devolue a cette couche est une fonction de 
multiplexage/demultiplexage. 
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Les communications avec la carte a puce 2a s'effectuent selon un paradigme 
similaire a celui utilise pour la manipulation de fichiers dans un systems 
d'exploitation du type "UNIX" (marque depos6e) : OUVRIR ("OPEN"), LIRE 
("READ"), ECRIRE ('WRITE"), FERMER ("CLOSE"), etc. 
Du cote de la carte a puce 2a, on retrouve une organisation similaire, d savoir 
la presence de deux couches basses, r6f6renc6es CCai (couche physique) et 
CCa2 (couche de lien de donnees), ainsi qu'une couche d'interface 26a, tout d 
fait similaire d la couche 16. 

Selon une premiere caractSristique importante, on prevoit, de part et d'autre, 
c'est-^-dire dans le terminal 1 et dans la carte a puce 2a, deux couches de 
protocoles sp6cifiques : 1 3 et 23a, respectivement. 

Dans le terminal 1, la couche specifique 13 s'interface aux "drivers couches 
basses" 15, aux bibliotheques 14 des couches reseau, C3 et C4, et aux 
couches protocolaires du lecteur de carte 3, c'est-S-dire les couches 
inferieures, CC1 et CC2, via la couche de multiplexage 16. La couche 
sp6cifique 13 permet le transfert des paquets reseaux de et vers la carte d 
puce 2a. En outre, elle adapte les applications existantes telles le navigateur 
Internet 10 (figure 2), le courrier electronique, etc., pour des utilisations mettant 
en ceuvre la carte d puce 2a. 

Du c6t6 de la carte & puce 2a, on retrouve une organisation tout d fait similaire 
constitute par une instance supplemental de la couche sp6cifique, 
r6f6renc6e 23a, pendant de la couche 1 3. 

Defa?on plus precise, les couches sptcifiques, 13 et 23a, sont subdivis§es en 
trois 6l6ments logiciels principaux : 

- un module, 130 ou 230a, de transfert de blocs d* informations entre les 
couches 13 et 23a, via les couches conventionnelles CCi, CC2. CCai et CCa2 

- une ou plusieurs pieces de logiciel, dites "agents intelligents", 132 ou 
232a, qui realisent, par exemple, des fonctions de conversion de protocoles ; 

- et un module de gestion de la configuration sp6cifique, 131 et 231a, 
respectivement ; module qui peut etre assimile £ un agent intelligent particulier. 



On retrouve done, dans le terminal 1 et la carte a puce 2a, une pile 
protocolaire de communication entre les deux entites. 

Les couches de niveau deux (couches de lien de donnees), CC2 et CC32, 
assurent I'echange entre la carte a puce 2a et le terminal 1. Ces couches sont 
responsables de la detection et I'eventuelle correction d'erreurs de 
transmission. Differents protocoles sont utilisables, et a titre d'exemples non 
exhaustifs les suivants : 

- la recommandation ETSI GSM 11.11 ; 

- le protocole d§fini par la norme ISO 7816-3, en mode caractere T=0 ; 

- le protocole defini par la norme ISO 7816-3, en mode bloc T=1 ; 

- ou le protocole dSfini par la norme ISO 3309, en mode trame "HDLC" 
(pour "High-Level Data Link Control procedure" ou procedure de commande de 
liaison a haut niveau). 

Dans le cadre de I'invention, on utilisera de preference le protocole ISO 7816- 
3, en mode bloc. 

De facon connue en soi, a chaque couche de protocole; il est associ§ un 
certain nombre de primitives qui permettent les echanges de donnees entre 
couches de merne niveau et d'une couche a I'autre. A titre d'exemple, les 
primitives associees a la couche de niveau deux sont du type "demande de 
donnees" ("Data.requesf) et "envoi de donnees" par la carte 
("Data.response"), ainsi que "confirmation de donnees" ("Data.confirm"), etc. 

De facon plus specifique, les couches 13 et 23a sont chargees du dialogue 
entre la carte a puce 2a et I'h6te, e'est-a-dire le terminal 1. Ces couches 
permettent I'echange d' informations entre un utilisateur (non represents) du 
terminal 1 et la carte a puce 2a, par exemple via des menus de>oulants sous la 
forme d'hypertexte au format "HTML". Elles permettent aussi la mise en place 
d'une configuration adaptee pour remission et/ou la reception de paquets de 
donnees. 

Comme il a ete indique ci-dessus, les couches comprennent trois entites 
distinctes. 



La premiere couche, 130 ou 230a, est essentiellement constitute par un 
multiplexeur logiciel. Elle permet I'echange d'informations entre la carte a puce 
2a et le terminal hdte 1 , sous la forme d'unit6s de donnees de protocole. Elle 
joue un r6le similaire a celui d'un commutateur de paquets de donnees. Ces 
unites sont emises ou recues via la couche de niveau 2 (couche de liens de 
donnees). Ce protocole particulier de communication permet de mettre en 
communication au moins une paire d' "agents intelligents". Le premier agent de 
chaque paire, 132, est situe dans la couche 13, cote terminal 1, le second. 
232a, est situe dans la couche 23a, cote carte a puce 2a. Une liaison entre 
deux "agents intelligents" est associee a une session. Une session est un 
^change de donnees bidirectionnel entre ces deux agents. 
Un agent intelligent peut realiser tout ou partie de fonctions des couches de 
niveau trois et quatre, en fonction de la configuration mise en oeuvre par le 
terminal 1 . 

Un agent intelligent particulier est identifie avantageusement par un nombre 
entier, par exemple sur 16 bits (nombre compris entre 0 et 65535). Cet 
identificateur est utilise, par exemple, dans une unite de donnee de protocole 
constituant une reference de destination et une reference de source. 
II existe deux grandes categories d'agents intelligents : les agents de type 
"serveur", qui sont identifies par une reference fixe, et les agents de type 
"client", qui sont identifies par une reference variable, delivree par le module 
de gestion de configuration, 131 ou 231a. 

Le processus d'ouverture d'une session est habituellement le suivant : un 
agent intelligent de type "client" ouvre la session vers un agent intelligent de 
type "serveur". Les couches 130 et 230a gerent des tables (non representees) 
qui contiennent la liste des agents intelligents presents, cote terminal hdte 1 et 
carte a puce 2a. 

Les agents intelligents sont associes a des proprietes ou attributs particuliers. 
Pour fixer les idees, et a titre d'exemple non limitatif, les six proprietes 
suivantes sont associees aux agents intelligents : 
"hdte" : agent localise dans le terminal ; 
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"carte" : agent localise dans ia carte a puce ; 

"local" : agent ne communiquant pas avec le reseau ; 

"reseau" : agent communiquant avec le reseau ; 

"client" : agent qui initialise une session ; 

"serveur" : agent qui recoit une demande de session. 
Les agents intelligents permettent d'echanger des donnees (de I'hypertexte 
par exemple), mais egalement de declencher des transactions reseau. 
Les modules de gestion de configuration, 131 et231a, respectivement, sont 
assimilables, comme il a ete indique, a des agents intelligents particuliers. Par 
exemple, le module 131, cote terminal hotel, gere notamment des 
informations relatives a la configuration de ce terminal (modes de 
fonctionnement), liste des autres agents intelligents presents, etc. Le module 
231a, cote carte a puce 2a, a des fonctions analogues. Ces deux agents 
intelligents peuvent etre mis en communication I'un avec I'autre pour etablir 
une session. * 

Selon une caracteristique importante, la carte a puce 2a propose au systeme 
hfite, c'est-a-dire au terminal 1, un modele de terminal virtuel. Pour ce faire, la 
carte a puce 2a se comporte comme un serveur "WEB". 

La carte a puce 2a est "adressee" par le navigateur 10. Elle lui transmet alors 
une page de type "WEB" en langage "HTML", un "applet" ou toute autre piece 
de logiciel. A titre d'exemple, la page "WEB" peut se presenter sous la forme 
d'une page d'accueil donnant un choix d'applications possibles et/ou 
d'hyperliens vers des serveurs exterieurs. 

De facon pratique, la carte a puce 2a est avantageusement "adressee" par 
utilisation d'une adresse "URL" (pour "Universal Resource Locator) definissant 
un rebouclage sur le terminal 1 lui-m§me, et non un pointage sur un serveur 
externe. A titre d'exemple, la structure de cette "URL" est habituellement la 
suivante: 

http://1 27.0.0. 1:8080 (1), 
dans lequelle 127.0.0.1 est I'adresse "IP" de rebouclage et 8080 est le numero 
de port. 
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La figure 3 illustre de facon simplifiee I'architecture logique d'un systeme dont 
la carte a puce 2a comprend des agents intelligents, dont deux seulement ont 
ete represents : un agent intelligent de type non precisement defini 232a2 et 
un agent intelligent 232ai, de type dit "WEB". La pile logique comprend, les 
couches de protocole inferieures, referencees 200a, repondant aux normes 
ISO 7816-3 (figure 2 : CCai et CCa2), le gestionnaire de commandes "APDU" 
201 ai, et le multiplexeur de paquets230a, ce dernier etant interface aux 
agents intelligents, notamment I'agent intelligent "WEB" 232ai . 
Du cdte terminal, il existe deux piles, Tune communiquant avec le reseau 
Internet Rl, I'autre avec la carte a puce 2a. La premiere pile comprend les 
organes 1 1 (figure 2 : Ci et C2) d'acces au reseau (normes OSI 1 et 2) et les 
couches de protocole 'TCP/IP" (figure 2 : C3 et C4), referencees 100. Ces 
dernieres couches sont interfacees avec le navigateur "WEB" 10. L'autre pile 
comprend les couches de protocole inferieures, referencees 101, repondant 
aux normes ISO 7816-3 (figure 2 : Ci et C2). le gestionnaire 102 d'ordres 
"APDU" et le multiplexeur de paquets 130, ce dernier etant interface avec des 
agents intelligents, dont un seul 132, est represents. Ce dernier, que I'on 
supposera de "type reseau", peut en outre communiquer, d'une part avec le 
navigateur 10, via les couches 'TCP/IP" 100, d'autre part avec le reseau 
Internet Rl, via ces memes couches 'TCP/IP" 100 et I'organe 11, d'acces au 
reseau Rl. 

Le gestionnaire d'ordres "APDU" 201a est egalement interface avec une ou 
plusieurs couches de niveau applications, que I'on appellera simplement 
applications. Ces applications sont, comme il a ete indique, des applications de 
type conventionnel, que Ton a appele "cardlet". 

En resume, la fonction "serveur WEB", fournie par la carte a puce 2a, peut 
etre realisee par I'association de I'agent intelligent "WEB" 232ai dans la carte 
a puce et de I'agent reseau 132 dans le terminal 1 . 

La carte a puce 2a presente done bien la fonctionnalite serveur "WEB". En 
outre, selon une caracteristique importante du procede de I'invention, n'importe 
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quelle application conventionnelle, A^ a A n , du type "CGA" precite, peut etre 
activee au travers de ce serveur "WEB", sort par le navigateur "WEB"' 10 
present dans le terminal 1, soit par un navigateur eloigne, localise en un point 
quelconque du reseau Internet Rl. Selon le procede de I'invention, les 
applications, A] a An, ne necessitent pas d'etre re-ecrites et sont mises en 
ceuvre telles quelles. 

Selon une autre caracteristique de I'invention, ces applications restent 
accessibles a un terminal de type conventionnel, c'est-a-dire conforme a I'art 
connu. 

Pour repondre a ces exigences, la fonction serveur "WEB", offerte par la carte 
a puce 2a, inclut un mecanisme similaire a la fonction dite "CGI" (pour 
"Common Gateway Interface") implantee dans les serveurs "WEB" classiques. 

Avant de decrire un exemple d'architecture conforme a I'invention, permettant 
de realiser une fonction de ce type. au sein meme de la carte a puce, il est utile 
de rappeler les principales caracterjstiques, d'un mode de fonctionnement 
"CGI". 

Le "CGI" est une specification de mise en ceuvre, depuis un serveur "WEB", 
d'applications ecrites pour les systdmes d'exploitation "UNIX" (marque 
deposee), "DOS", ou "WINDOWS" (marque deposee). A titre d'exemple, pour 
le systeme d'exploitation "UNIX", la specification est "CG1 1.1" et pour le 
systeme d'exploitation "WINDOWS 95", la specification est "CG1 1.3". 
Toujours a titre d'exemple, une requete "HTTP" du type : 

"http://www.host.com/cgi-bin/xxx.cgi" (2), 
dans laquelle "host" se refere a un systeme note (generalement eloigne), est 
interpretee par un serveur "WEB" comme I'execution d'un script de commande, 
de type "CGI" nomme "xxx" et present dans le repertoire^'cgi-bin" de ce 
systeme hote. Bien que le nom du repertoire puisse §tre a priori quelconque, 
par convention, c'est le nom donne au repertoire stockant les scripts de type 
"CGI". Un script est une suite ^instructions du systeme d'exploitation du 
systeme hdte dont le resultat final est transmis au navigateur "WEB" emetteur 
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de la requete precitee. Differents langages peuvent etre utilises pour ecrire ce 
script, par exemple le langage "PERL" (marque deposee). 
De facon pratique, la requete est habituellement affichee sur un ecran 
informatique sous la forme d'un formulaire compris dans une page "HTML". Le 
langage "HTML" permet de traduire un formulaire en une adresse "URL". Le 
formulaire comporte un ou plusieurs champs, obligatoires ou non, qui sont 
remplis par un utilisateur a I'aide des moyens de saisie habituels : clavier pour 
le texte, souris pour les cases a cocher ou les boutons dits "radio", etc. Le 
contenu du formulaire (ainsi qu'eventuellement des informations et instructions 
dites "cachees") est emis a destination du serveur "WEB". Le code "HTML" de 
la page decrit la structure materielle du formulaire (cadre, graphisme, couleur, 
et tout autre attribut), ainsi que la structure des champs de donnees a saisir 
(nom, longueur, type de donnees, etc.). 

La transmission peut s'effectuer selon deux types de formats principaux. Un 
premier format utilise la methode dite "POST' et un second la methode dite 
"GET'. Une information de type de format est presente dans le code de la page 
formulaire. 

Ce mecanisme n'est cependant pas directement transposable a une carte a 
puce, meme si celle-ci offre la fonctionnalite serveur "WEB" conformement a 
Tune des caracteristiques de I'invention. 

On va maintenant decrire un exemple d'architecture permettant d'activer une 
application quelconque, de type conventionnel, via un serveur "WEB" sur la 
carte a puce 2a, par reference a la figure 4. 

Lors d'une premiere etape, un utilisateur (non represente) invoque depuis son 
navigateur "WEB" (figure 3 :10) une "URL" qui peut se presenter de la facon 
suivante : 

,, http://@carte:8080/xxx.html" (3), 
dans laquelle "@carte" est une adresse IP de la carte a puce (par exemple 
I'adresse de rebouclage "127.0.01" precedemment decrite : voirformule (1)), et 
"xxxhtml" est une page en langage "HTML" relative a une application 
particuliere "xxx" offerte par la carte a puce. 
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Lors d'une deuxieme etape, de la maniere decrite precedemment, la carte a 
puce renvoie une page "HTML", par exemple de type formulaire. 

Lors d'une troisieme etape I'utilisateur renseigne les champs du formulaire et 
en transmet le contenu a la carte & puce, habitue lie ment en cliquant sur un 
champ particulier, de type "bouton poussoir". 

Les donnges sont alors 6mises et regues par I'agent r£seau 132. Les donn£es 
traversent alors le multiplexeur de paquets 130 (qui constitue Tun des 
composants de la couche specifique 13, cote terminal 1), le gestionnaire 
d'ordres "APDU" 102, les couches protocolaires 101, pour §tre transmises k la 
carte d puce 2a. Elles traversent ensuite les couches protocolaires 200a, le 
gestionnaire d'ordres "APDU" 201 a, le multiplexeur de paquets 230a pour §tre 
regues par I'agent "WEB" 232ai. II s'6tablit done une session logique entre les 
deux agents intelligents, comme explicits precedemment. 

II convient de remarquer que les donnees adress6es a I'agent "WEB" 232ai 
sont transport6es, de fagon conventionnelle en soi, sous formes d'ordres 
"APDU" destines a ('application particuliere "Multiplexeur de paquets". Le 
gestionnaire d'ordres "APDU" 201 a selectionne cette application de manure 
tout a fait similaire aux autres applications de type "CGA" pr§sentes dans la 
carte d puce 2a, r§ferencees Ai a An. En d'autres termes, le multiplexeur de 
paquets 230a est vu par le gestionnaire d'ordres "APDU" 201a comme une 
application "CGA" ordinaire. 

La requfete "HTTP" est analysee par I'agent "WEB" 232at qui d§tecte une 
ref6rence & un repertoire particulier, que Ton appellera ci-apr&s par convention 
"cgi-smart", d'une part, et a une application particuliere, par exemple "xxx" dans 
le cas de Pexemple decrit, d'autre part. Le chemin complet est done, en 
I'occurrence "cgi-smart/xxx". 

Selon une caract6ristique importante du procede de I'invention, I'entitd ci- 
dessus designe un script particulier associe & une application egalement 
particuliere "xxx". 
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Lors d'une quatrieme etape, le script est interprets par un agent intelligent dit 
"Agent traducteur de script", que Ton appellera "ATS" ci-apres. Cette traduction 
peut §tre realisee de differentes manieres : 

a/ par I'agent "WEB" 232ai lui-meme, qui est dote dans ce cas d'une double 
capacite ; 

b/ par un agent traducteur de script unique capable de traduire I'ensemble 
des scripts presents dans la carte a puce 2a ; 

cl par un agent de script dedie que Ton appellera "ATSD" ci-apres (un par 
script) ; ou 

61 par un agent "APDU" 2010a du gestionnaire d'ordres "APDU" 201a, qui 
est dote, dans ce cas, d'une double capacite. 

L'agent "APDU" 2010a est une composante de la couche gestionnaire d'ordres 
"APDU" 201a. Cette derniere, comme il a ete indique, est une couche capable 
de centraliser tous les ordres "APDU" emis et/ou recus par le systeme, de 
selectionner des applications, parmi A<\ a A n , mais egalement d'offrir une 
interface de type agent intelligent. Elle est done capable, selon Tune des 
caracteristiques du procede, de communiquer avec tous les agents intelligents 
du systeme (via des sessions), que ces agents soient localises dans le terminal 
1 ou la carte a puce 2a. 

Dans le cas cJ ci-dessus, une session est ouverte entre I'agent "WEB" 232ai 
et I'un des agents "ATSD". 

La figure 4 illustre un exemple d'architecture pour laquelle les agents 
traducteurs sont du type "ATSD". lis sont references /\TS1 a ATSn et associes 
aux applications A-] a Ap. L'application selectionnee etant supposee §tre 
I'appiication Aj, la session s'etablit entre I'agent "WEB" 232ai et I'agent ATS\. 
Un agent traducteur de script genere une suite d'ordres "APDU". Une session 
est ouverte entre I'agent traducteur, par exemple I'agent ATSi, et I'agent 
"APDU" 2010a. Les ordres sont alors emis vers I'agent "APDU" 2010a. Le 
gestionnaire d'ordres "APDU" 201a selectionne l'application "CGA" Aj (par 
exemple I'appiication "PME") et lui transmet les ordres "APDU", ordres traduits 
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et done conventionnels, qu'elle est en mesure de comprendre. Cette 
application est done conrectement activee, sans avoir a la modifier ou a la 
reecrire. 

Les reponses de I'application "CGA" Aj sont transmises au gestionnaire 
d'ordres "APDU" 201a, a I'agent "APDU" 2010a, puis de nouveau a I'agent 
ATSj (et de facon plus generate a I'agent traducteur de script). 

En fonction de la reussite ou de I'echec du deroulement du script, I'agent 
traducteur de script, par exemple I'agent ATSj dans I'exemple de la figure 4, 
elabore une page en langage "HTML" et la transmet via les differentes couches 
empruntees par la requete initiate, mais en sens inverse, ce pour etre 
presentee sur I'ecran de visualisation 5 (figure 1A). 

Les differents cheminements sont representes symboliquement sur la figure 4 
par des traits pleins reliant les blocs fonctionnels ou en pointilles a I'interieur de 
ces blocs. 

La figure 5 resume de facon schematique les principales Stapes du processus 
qui vient d'etre decrit : 

a/ transmission via le reseau Internet Rl (ou a partir du terminal local : dans 
les deux cas a I'aide d'un navigateur conventionnel 10) d'une requ§te "HTTP", 
referencee RQ ; 

b/ reponse du serveur "WEB" de la carte a puce 2a, sous la forme d'un 
formulaire, reference FO ; 

cl transmission du formulaire rempli, sous la forme d'une nouvelle requ&te 
RQ;et 

d/ reponse sous la forme d'une page "HTML", referencee PR. 
La reponse pourrait d'ailleurs consister en la transmission d'un fichier, ou 
d'une piece de logiciel ou "Applet"; 

En mettant en csuvre les mecanismes et fonctions qui viennent d'§tre decrits, 
notamment la fonction serveur "WEB" et le recours a des agents intelligents 
traducteurs de scripts, selon une caracteristique essentielle, le procede selon 
I'invention va permettre de definir un environnement virtuel, avantageusement 
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securise par la carte a puce. Dans un mode de realisation prefere, cet 
environnement est compatible avec les applications de type dit multimedia. 
Cette derniere caracteristique est particulierement avantageuse car les 
navigateurs "WEB" recents, mais de type tout a fait classique en soi, 
permettent, par nature, de construire des environnements multimedias (images 
animees, sons, etc.). lis sont en effet associes a des outils logiciels, integres 
ou non, permettant de manipuler des fichiers multimedia (visionneuse, etc.). En 
tout etat de cause, les navigateurs permettent de telecharger des fichiers de 
donnees multimedias, habituellement volumineux et de les stocker sur un 
disque dur, par exemple dans le terminal, ou sur un organe de stockage de 
masse similaire. On a notamment propose des technologies permettant 
I'affichage en temps reel ou quasi-reel de sequences videos ou la reproduction 
de son, a partir de sites "WEB" du reseau Internet. 

Cependant, une carte a puce, comme il a ete rappele, ne presents qu'une 
faible capacite de m6moire. En outre, elle n'autorise qu'un tres faible debit de 
donnees lors des echanges. II n'est done pas possible d'enregistrer un grand 
nombre de fichiers de donnees dans celle-ci. II n'est pas non plus 
envisageable, de facon pratique, de stocker des fichiers multimedias, a 
I'exception de tres courtes sequences ou de sequences sonores codees sous 
un format particulier, tel que le codage "MIDI". 

En dehors de ces limitations d'ordre technologique, il est aussi souhaitable de 
pouvoir avoir acces a des applications eloignees, tout en beneficiant d'une 
securisation de haut niveau, que seule la mise en ceuvre d'une carte a puce est 
apte a offrir. 

Le procede selon invention permet ce mode de fonctionnement. 
L'environnement virtuel multimedia securise par carte a puce, selon un mode 
de realisation prefere, permet de : 

definir des objets virtuels auxquels la carte a puce peut acceder ; 

fournir des methodes d'acces a ces objets. 
La figure 6 illustre schematiquement cet aspect essentiel du procede selon 
I'invention. 
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Un utilisateur Uj interroge la carte a puce 2a grace au havigateur "WEB" 1 0 
compris dans le terminal 1 . Selon un mScanisme qui va etre precise ci-apres, 
grace notamment a la fonction "serveur WEB" precedemment d6crite, la carte d 
puce 2a va renvoyer au navigateur une liste d'objets dits virtuels Obvj t / §tant 
un indice arbitrage, auquel il a acces, c'est-S-dire de fagon pratique pour 
lesquels la carte a puce 2a ou I'utilisateur Uj possede des droits d'acces. En 
effet, ces droits d'accds peuvent etre lies strictement a la carte a puce 2a et 
immuables. Ms peuvent egalement etre lies a un profil utilisateur, I'utilisateur Uj 
fournissant, par exemple, des donnees ^identification et un mot de passe. La 
carte a puce 2a effectue une verification par comparaison avec des donndes 
d'une base de donnees de s6curite enregistrees dans une m§moire fixe et, si le 
resultat de la comparaison est positif, fournit une liste d'objets virtuels Obvj 
associ6e au couple : "donnees ^identification - mot de passe". De fa$on 
connue en soi, cette premiere phase peut mettre en ceuvre un proc§d£ de 
chiffrage des donn6es 6chang6es entre le terminal et la carte d puce 2a ou 
mettre en ceuvre un protocole de transmission securise "HTTPS". La carte d 
puce 2a va egalement fournir une liste de methodes d'acc6s aux objets virtuels 
Obvj. 

Les objets virtuels Obvj, qui sont de type statique ou dynamique comme 
indiqu§ precedemment, peuvent etre localises indifferemment dans la carte d 
puce 2a, ou dans le terminal 1, ou, de fa$on plus generate, dans un systdme 
quelconque connecte au reseau Internet RL Selon une caracteristique 
importante de Tinvention, cet emplacement est "transparent" pour le navigateur 
10, et done pour Tutilisateur Uj, comme il va I'etre montre. 

Le proced6 selon Tinvention fait appel notamment a ce qui va etre appele ci- 
apres un systdme de gestion de fichier virtuel, ou "SGFV, et un agent 
intelligent traducteur de script specialise, que Ton appellera "ATSDA/SGVF" 
dedie a cette tache. Cet agent intelligent fournit la liste des objets virtuels Obvj 
auxquels la carte a puce 2a peut acceder. Une adresse "URL" particulfere est 
associ^e a chaque objet virtuel Obvj. L'invocation de cette "URL" depuis le 
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navigateur "WEB" 10 permet d'instancier I'objet virtue! Obvu au moyen d'une 
methode d'appel d6termin6e, specifique ou non a cet objet. 
On va tout d'abord rappeler bridvement les principales caracteristiques <fun 
systeme de gestion de fichiers classique, appeie ci-apr6s "SGF". Un tel 
systeme est utilise pour stocker de I'information sur un support tel qu'un disque 
dur. L'information est m6morisee sous la forme d'un fichier. Un fichier, que ce 
soit des donn6es pures ou des instructions de programme, est compose 
classiquement d'une suite de blocs de taille fixe. Un mecanisme bien connu 
permet d'obtenir la liste des blocs de memoire qui constitue le fichier et leurs 
adresses dans la memoire. 

Un repertoire est un fichier particulier dont le contenu est une liste de 
descripteurs de fichier. Un tel descripteur comprend par exemple les elements 
suivants : 

le nom du fichier ; 

la longueur du fichier ; 

la date de creation ; 

une reference permettant de retrouver la liste des blocs du fichier 
(num6ro du premier bloc, tableau des numeros de blocs, etc.) ; et 

et des attributs qui specifient des propriet6s particulidres du fichier 
(repertoire, lecture, 6criture, execution, etc.). 

Le premier repertoire est habituellement appeie repertoire racine. Un 
repertoire qui n'est pas racine est dit sous-repertoire. Le repertoire qui contient 
le descripteur d'un fichier donn6 est son repertoire pere. L'adresse d'un fichier 
dans le "SGF" est done une succession de noms de repertoires, depuis le 
repertoire racine jusqu'au repertoire pfere du fichier, ce qui d6finit un chemin. A 
titre d'exemple, un tel chemin se pr6sente comme suit : 

,, /racine/repe^toire1/repe^toire2/nom - du_fichier ,, (4), 
les chiffres 1 et 2 6tant arbitrages, "racine" etant le nom du repertoire racine et 
"nom_de_fichier" un nom quelconque de fichier. 

Pour une carte & puce, la norme ISO 7816-4 definit le repertoire racine dit 
"MF" (pour "Master File" ou fichier maitre), des sous-repertoires dits "DF M (pour 



26 

"Dedicated Files" ou fichiers dedies) et des fichiers elementaires dits "EF" 
(pour "Elementary Files). 

Dans le cadre de I'invention, le systeme de gestion de fichiers "SGFV", que 
Ton appellera virtuel, permet de definir des objets virtuels Obvj auxquels la 
carte a puce 2a peut avoir acces. Selon le precede de I'invention, un objet 
virtuel Oovy est associe a un fichier elementaire virtueL Le contenu d'un fichier 
elementaire virtuel est constitue par I'ensemble des informations qui permettent 
d'acceder a I'objet virtuel associe Obvj et d'en obtenir une instance dans le 
terminal 1. 

De facon pratique, comme illustre schematiquement par la figure 7, le systeme 
"SGFV" peut constituer un sous-ensemble d'un systeme "SGF" classique, et, 
de facon plus precise, un "SGFV" est loge a I'interieur d'un fichier elementaire, 
tel que definit par la norme ISO 781 6-4 precitee. 

Un descripteur de fichier comportera generalement les elements suivants : 
le nom du fichier ; 
la longueur du fichier ; 
la date de creation ; . 

une reference (avantageusement un nombre entier) qui permet de 
retrouver la liste des blocs du fichier (numero du premier bloc, tableau de 
numeros de blocs, etc.) • un fichier virtuel est identifie par son nom ou cette 
reference unique ; et 

des attributs du fichier qui specifient les references particulieres du fichier 
: repertoire ou fichier elementaire, virtuel ou non virtuel, direct ou indirect. 

On appelle "objet virtuel direct", un objet qui est instancie depuis la 
carte a puce 2a.- Jl s'agit typiquement d'un objet virtuel Obvj statique qui peut 
§tre manipule par le navigateur, par exemple affich§ (image, etc.). On appelle " 
objet virtuel indirect'*; un objet virtuel Oov/ qui est instancie^depuis le navigateur 
10, typiquement a I'aide d'un "applet". 

La figure 8 illustre schematiquement I'architecture d'un systeme a 
carte a puce permettant d'instancier un objet virtuel Obvj localise a un endroit 
quelconque du reseau Internet Rl, via le navigateur 10 et la carte a puce 2a. 
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Les elements communs aux figures precedentes portent les memes references 
et ne seront re-decrits qu'en tant que de besoin. 

L'architecture illustree sur la figure 8 est tres similaire a celle de la 
figure 4. La difference essentielle est constitute par le fait que I'on a prevu un 
"SGFV" 8, stocke dans la carte a puce 2a, et un agent intelligent traducteur de 
script specifique "ATSDA/SGFV", reference 7. Le mode de fonctionnement est 
similaire a celui illustre par la figure 4 lorsque Ton desire acceder a une 
application particuliere Aj. II est done inutile de le re-decrire en detail. Dans le 
cas present I'application particuliere est remplacee par le systeme de gestion 
de fichuer virtuel "SGFV" 8. On etablit tout d'abord une session entre I'agent 
intelligent reseau 132 et I'agent intelligent "WEB" 232ai. Selon le mecanisme 
precedemment explicite, il s'etablit ensuite une session entre I'agent 
"WEB" 232ai et I'agent intelligent "ATSDA/SGFV" 7. 

De facon pratique, I'agent intelligent "ATSDA/SGFV" 7 est accessible 
par des "URL", typiquement du type : 

"http://www.host.com/cgi-smart/sgfv?" (5), 
dans lesquelles "sgfv" est une application de type "CGI" associee a I'agent 
intelligent "ATSDA/SGFV" 7. La requete ci-dessus permet de parcourir I'arbre 
des repertoires et de "montrer" leur contenu au navigateur 1 0, au moyeh d'une 
page "HTML". Les "feuilles "de I'arbre sont des fichiers elementaires, virtuels 
ou non virtuels, associes a un hyperlien. La transmission dans le sens "carte a 
puce 2a - terminal 1" est realisee de la maniere qui a ete explicitee en regard 
de la figure 4. 

En d'autres termes, I'agent intelligent "ATSDA/SGFV" 7 associe a tout element 
du "SGFV" 8, repertoire ou fichier elementaire, une adresse "URL". L'adresse 
"URL" d'un repertoire designe une page "HTML" qui contient la liste de ses 
elements. L'adresse "URL" d'un fichier elementaire permet de creer une 
instance de I'objet virtuel Obvj associe a ce fichier virtuel. 
Pour fixer les idees, si on utilise l'adresse "URL" (5) ci-dessus, on obtient une 
page "HTML" qui presente le contenu du repertoire racine au navigateur 10. Ce 
repertoire racine est constitue par un ensemble de sous-repertoires et de 
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fichiers comme illustre schematiquement par la figure 9. Sur cette figure, on a 
represents un repertoire racine rep#0 1 au niveau superieur, un fichier 
6l§mentaire reel fe#7 et un sous-repertoire r6el srep#1, au niveau 
imm§diatement inferieur, et un sous-r6pertoire virtuel rep#2 et un fichier 
etementaire virtuel fe#5, au niveau le plus bas, tous deux dependants du sous- 
r6pertoire reel srep#1 , les num6ros de reference etant purement arbitrages . 

Lors d'une premiere phase, I'agent intelligent "ATSDA/SGFV 1 7 
transmet au navigateur 10, en r6ponse a la requete regue, une page "HTML" 
(non representee) montrant, sous une forme ou une autre, la structure 
hierarchique du "SGFV" 8. La page est habituellement affich6e sur un 6cran de 
visualisation (figure 1A : 5), par exemple sous la forme d'un menu. Chaque 
ligne du menu est constitute d'un hyperlien decrivant un sous-repertoire ou un 
fichier 6lernentaire. L'affichage peut etre avantageusement sous forme 
graphique, associee ou non a un texte descriptif, le dessin de Parbre de la 
figure 9 §tant affiche sur i'ecran precite. On peut encore afficher des icones ou 
des formes complexes (par exemple en 3 dimensions), chacune etant associee 
S I'un des objets virtuels S instancier, et pouvant etre representative de leur 
nature (3 titre d'exemple, une camera representant un fichier vid6o), associ6e 
ou non £ un texte descriptif 

Uutilisateur Uj est invite a cliquer sur un hyperlien (sur un noeud ou sur 
une branche dans le cas d'un graphique). Par cette action, il va pouvoir obtenir 
une instance de Pobjet virtuel Obvj desire. 

Le systeme "SGFV 8 est avantageusement enregistre dans une memoire de 
type re-programmable comprise dans la carte a puce 2a, par exemple du type 
"EEPROM" (memoire effagable electriquement), comme illustr§ 
schematiquement sur la figure 10. Le "SGFV 1 8 reproduit la structure de I'arbre 
de la figure 9. 

Toujours dans I'exemple decrit, une fois obtenu la page de menu, 
obtenue lors d'une phase initiate, en cliquant sur une "URL" qui pourrait etre 
typiquement la suivante : 

"http://www.host.eom/cgi-smart/file#5 (6), 
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I'utilisateur Uj obtient une instance de Tobjet virtuel Obvs associe au fichier 
elementaire reference fe#5 sur la figure 10. De meme, il aurait pu obtenir le 
contenu d'un sous-repertoire, le parametre "file#5" etant remplacg par M ff/e#x" 
dans (6), #x etant le num6ro associe au sous-repertoire. 

Les fichiers non virtuels sont enregistres dans la carte d puce 2a et 
sont conformes au paradigme usuel qui gouverne les "SGF\ lis contiennent 
des donn6es, telles que par exemple des cl6s, donn6es utiles d I'agent 
intelligent "ATSDA/SGFV 7. 

Differentes conventions sont possibles quant d la definition des 
informations n6cessaires a I'instanciation d'un objet virtuel Obvu et par exemple 

un fichier virtuel de longueur nulle herite des methodes d'acc£s de son 
repertoire pdre ; 

un repertoire virtuel est associe a un fichier 6l6mentaire virtuel dont le 
nom est impose (par exemple 'Virtual"), et qui contient les methodes d'accds de 
ce repertoire. 

En effet, outre la liste des objets virtuels accessible Obvu un agent 
intelligent "ATSDA/SGFV" 7 doit egalement fournir une methode d'acc&s d un 
objet virtuel donne Obvu ce £ partir de tout ou partie des informations 
contenues dans un fichier virtuel elementaire. La figure 11 illustre 
schematiquement ce processus. 

Selon le proc6d6 de Tinvention, on pr6voit deux methodes d'acces, 
que Ton appellera directe et indirecte, respectivement, en fonction des attributs 
du fichier elementaire virtuel considere. 

La methode directe consiste en une description d'une chalne d'agents 
intelligents mis en ceuvre dans le processus permettant d'acc6der d un objet 
virtuel Obvj et d'en obtenir une instance dans le terminal. Lors de I'ouverture 
d'une session, un agent intelligent donn6 re$oit, de I'agent qui initie cette 
session, une liste de structures d'appel qui sera d6nommee ci-apr6s "methode 
d'appel" ou encore "Method PDU" (pour "Method Protocol Data Unit"). 
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Une structure d'appel comprend : 

- un identificateur de I'agent intelligent avec lequel la session est ouverte ; 

- des donnees, ou argument, necessaires a son utilisation. 

Le premier agent intelligent adresse par la liste precitee "consomme" 
une premiere structure d'appel qui lui est destinee. II transmet le reste de la 
liste de structure a un agent intelligent suivant, avec lequel il etablit une 
session, jusqu'a epuisement de la liste. 

Pour fixer les idees, un exemple des differentes etapes d'echanges 
entre I'agent intelligent "ATSDA/SGFV" 7 et deux agents intelligents en 
cascade, 232am et 232an, est illustre schematiquement par la figure 12. La 
liste de structure d'appel emise par I'agent intelligent "ATSDA/SGFV" 7 
comporte en realite deux sous-listes distinctes, reperees #1 et#2 dans leurs 
en-tetes, respectivement. La premiere est consommee par le premier agent 
intelligent, 232am. et la seconde par le second agent intelligent, 232a/j. Un 
agent intelligent, par exemple I'agent intelligent 232am, esUidentifie par une 
reference, ou identificateur d'agent ("Identificateur Agent m" ou "Identificateur 
Agent #2"). L'agent intelligent adresse, et avec lequel s'etablit une session, 
retient la sous-liste qui lui est destinee grace a I'en-tete ("Structure d'Appel #1 
ou "Structure d'Appel #2"). Les arguments de la sous-liste qu'il retient 
("Argumentttr ou "Argument#1") sont constitues par un ensemble de donnees 
utiles au bon fonctionnement de cet agent. A titre d'exemple, une donnee peut 
etre un nom de fichier (non virtuel ou virtuel direct). 

Un agent intelligent donne, par exemple I'agent intelligent 232am, peut 
modifier le reste de la liste de structure d'appel avant de la transmettre a 
I'agent intelligent suivant, 232an- Pour ce faire, il adresse cet agent intelligent, 
232an, et etablit une session avec lui. 

La methode d'appel peut etre avantageusement decrite au moyen du 
langage ASN.1 (Abstract Syntax Notation 1" de I'ISO) 

La methode d'acces directe permet en definitive d'instancier un objet 
virtuel Obvj directement depuis la carte a puce 2a. II s'agit a priori d'un objet 
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statique. L'objet instancie se presente habituellement sous la forme d'une page 
"HTML" ou d'un "applet" transmis au navigateur 10. 

La seconde methode d'acces, ou methode d'acces indirect, est en realite 
egalement une methode d'acces direct, mais mise en ceuvre a partir du 
terminal 1 , et non plus de la carte a puce 2a. Cette methode est 
essentiellement utilisee pour instancier des objets virtuels Obvj du type 
dynamique. 

Selon cette variante du precede, en reponse a un "URL" qui d£signe un fichier 
elementaire virtuel fe#x, I'agent intelligent "ATSDA/SGFV" 7 transmet au 
navigateur 10 une page "HTML" qui comporte un hyperlien pointant sur la 
methode d'acces directe associee a l'objet virtuel Obvj 

Deux variantes peuyent etre mises en ceuvre. 

La premiere variante consiste a utiliser un "applet". Le lien sur la methode 
d'acces est alors un "applet" localise a I'adresse "@carfe", qui peut elle-meme 
etre designee par : 

le nom (c'est-a-dire une "URL") d'un fichier non virtuel, enregistre sur la 
carte a puce 2a; 

une "URL" qui designe un fichier virtuel direct. 
Un parametre d'appel de cet "applet" est une liste de structure d'appel, par 
exemple codee en ASN.1 comme indiqu§ ci-dessus. V "applet" content! dans 
une page "HTLM" est telecharge, depuis la carte a puce 2a ou le reseau 
Internet Rl, vers le navigateur 10, puis execute par celui-ci de facon obligatoire 
(forcage). Cet "applet" etablit une session avec un premier agent intelligent, 
arbitrairement reference 232ap. La connexion a cet agent intelligent 232ap 
utilise, par exemple, un modele d'echange de donnees du type client-serveur 
'TCP/IP" (c'est-a-dire la classe dite "socket JAVA"). L' "applet" se comporte 
comme un client 'TCP/IP" et se connecte a un serveur "TCP/IP" (ce dernier 
etant egalement un agent intelligent) identifie par I'adresse de la carte et un 
port : "@carte : port". 

La figure 13 illustre schematiquement les differentes phases des echanges 
permettant d'instancier un objet virtuel par la methode indirecte. On a repris sur 
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cette figure 13 les parametres de I'exemple precedemment decrit, en 
1'occuirence, le fichier elementaire virtuel fe#5, ce qui se traduit par I'adresse 
"URL" de la configuration (6) ci-desus. On a suppose que I'adresse de la carte 
a puce a utiliser est "@carte" et le port 8080. La requete est transmise a I'agent 
intelligent "ATSDA/SGFV" 7 selon le processus precedemment decrit. Celui-ci 
renvoie au navigateur 10 une page "HTML" P constitute par un "applet". Dans 
un but de simplification du dessin, les differentes instructions de cet "applet" 
ont ete resumees sur la figure 13 par la mention "CODE applet placee entre 
les marqueurs <applet ...> et </applet>. De facon connue en soi, r "applet" est 
associe a une classe "JAVA", que ion a appele arbitrairement "tv.clasg\ pour 
"terminal virtuel". Le code comprend egalement des instructions indiquant 
I'adresse du premier agent intelligent de la structure de liste , reference 232ap, 
et I'adresse et le port a utiliser, en I'occurrence I'adresse "@ca/te" et le port 
8081. II est a noter que cet agent intelligent 232ap peut etre localise dans la 
carte a puce 2a ou dans le terminal 1 . 

Chaque agent intelligent, par exemple 232ap, execute une tache precise: 
dechiffrement d'un message chiffre, verification de mots de passe et/ou de 
donnees de securite, conversion d'un fichier, d'un format a un autre, etc. Bien 
que Ton ait represente qu'un seul agent intelligent, 232ap, comme dans le cas 
precedent (figure 12) on peut prevoir, en tant que de besoin, plusieurs agents 
intelligents en cascade. Comme precedemment egalement chaque agent 
intelligent, 232a p , consomme une partie de la structure de liste, celle qui lui est 
destinee, et transmet le reste, inchange ou modifie, a I'agent intelligent suivant 
(non represente). 

Pour mieux illustrer la premiere variante, et pour fixer les idees, on va 
considerer que I'utilisateur Uj desire telecharger et executer .un fichier audio, 
code par exemple au format "MP3". Ce fichier constitue I'un des objets virtuels, 
ici reference FS, proposes par la page de menu "HTML" transmise par I'agent 
intelligent "ATSDA/SGFV" 7, lors de la phase initiate. La figure 14 illustre 
schematiquement la sequence d'etapes permettant d'instancier un tel objet 
virtuel, reference FS. On suppose que le navigateur 10 ne dispose pas d'un 
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lecteur approprie pour un tel format. Ce lecteur, reference LS, va etre cherch6 
sur un site Internet, qui peut §tre distinct ou non du site ou se trouve le fichier 
son FS. 

Dans I'exemple dScrit, la sequence d'etapes est la suivante. 
a/ I'utilisateur Uj clique sur un hyperlien (texte, ic&ne ou toute autre 
representation graphique de I'objet £ rechercher, c'est-S-dire le fichier FS) : 
une requ&te h est transmise § la carte d puce 2a ; 

b/ en r6ponse, R-| t une page "HTML" est transmise, par la carte d puce 2a, 
au terminal 1 et au navigateur 10 ; 

cl la page "HTML" regue force le navigateur 10 £ demander un "applet" : 
interrogation /2 (dans le cas present, il s'agit d'aller chercher le lecteur de son 
approprte LS) ; 

d/ en reponse, f?2. le lecteur recherche LS est t§lecharge et install^ dans le 
terminal 1 ; 

el le navigateur 10 adresse de nouveau la carte a puce 2a t requete /3, en 
vue d'obtenir une instance du fichier audio FS; et 

il en r6ponse, le navigateur 10 regoit ce fichier audio FS, ce dernier 
pouvant §tre lu, c'est-a-dire jou§ par le terminal 1 v qui dispose d§sormais du 
lecteur de son LS approprie. 

II est k noter que toutes les operations sont transparentes pour I'utilisateur Uj, 
plus precis§ment pour le navigateur 10, qui ne "connait" que la carte d puce 
2a. Le lecteur LS (ou de fagon plus generate un autre "applet") et/ou I'objet 
virtuel recherch6, c'est-^-dire le fichier FS dans Texemple, si leurs tallies 
avaient 6te compatibles avec la capacite de memorisation de la carte d puce 
2a, auraient d'ailleurs pu etre enregistr£s dans celle-ci (re-bouclages 
symbolisms par des traits en pointilles sur la figure 14). Le navigateur 10 ne 
connait pas la localisation exacte des objets virtuels Obvj. Seule la carte d 
puce 2a, de fagon plus precise Pagent intelligent "ATSDA/SGFV" 7, connait la 
localisation des objets virtuels de la liste du "SGFV" 8 et la m§thode pour y 
acc6der. 
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Dans une variante preferee du procede, I'agent intelligent "ATSDA/SGFV" 7 
connaTt egalement la liste des seuls objets virtuels accessibles a un utilisateur 
Uj donne (autorisations). II s'agit done bien d'un systeme securise. Le terme 
"securise" doit etre considere dans son sens le plus large. A titre d'exemple, il 
concerne aussi bien des cartes a peage donnant acces a certaines ressources, 
en fonction d'un abonnement determine par exemple, ou des cartes assurant 
un acces securise proprement dit a des ressources confidentielles, en fonction 
d'un niveau d'habilitation par exemple. Comme il a ete indique, les ressources 
ou objets virtuels Obvj peuvent etre constitutes par des transactions. 
Ces remarques s'appliquent d'ailleurs aussi pour les methodes d'acces direct. 
Cela constitue une caracteristique tres importante du procede selon I'invention. 
Selon une seconde variante, illustree schematiquement par la figure 15, on 
peut utiliser un hyperlien qui definit I'adresse 'TCP/IP" du premier agent 
intelligent associe a la methods d'acces. I'adresse est du type : 
"@Agent:AgentPort", avec "@Agent", I'adresse proprement dite de Pagent 
intelligent concerne et "AgentPort" le port de celui-ci. La liste "MethodPDU" est 
dans ce cas un parametre d'une "URL". L'hyperlien sera associe, par exemple 
a une image ou un formulaire d'une page "HTML" P'. 
Ainsi, a titre d'exemple, une "URL" ayant la structure suivante : 

http://@Agent:AgentPort/MethodPDU?Value=xx... (7), 
permet d'atteindre un agent intelligent qui se comporte comme un serveur 
"WEB TCP/IP", reference arbitrairement 232a q . Cet agent intelligent 232a Q est 
localise a I'adresse "@Agent:AgentPort" et recoit la liste de structure d'appel 
"MethodPDU", avec le parametre 'Value=xx...". 

Pour fixer les idees, on suppose que I'objet virtuel Obvj est une image a 
afficher sur un ecran (figure 1A :5), d'un format particulier, a I'aide du 
navigateur 10 et que celui-ci ne dispose pas d'un programme^approprid pour 
cet affichage, generalement appele visionneuse ou "viewer" selon la 
terminologie anglo-saxonne. II s'agit, par exemple, d'un programme executable 
sous le systeme Sexploitation utilise sur le terminal 1, de type "XXX.exe", avec 
"XXX" le nom de ce programme. L'action de cliquer sur l'hyperlien (7) ci-dessus 
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va permettre de rechercher ce programme executable, celui-ci pouvant etre 
localise dans le terminal 1 ou dans un syst§me 6loign§. 

La difference entre les deux variantes de realisation est que dans le premier 
cas, le navigateur se voit ,l force" de demander le chargement d'un "applet". 
Toutes les §tapes sont realisees automatiquement. Dans le second cas, 
Putilisateur Uj est invit6 S cliquer sur un hyperlien ou & ex6cuter une action 
similaire. 

A la lecture de ce qui precede, on constate ais§ment que P invention atteint 
bien les buts qu'elle s'est fixes. 

II doit fetre clair cependant que Pinvention n'est pas limitee aux seuls exemples 
de realisations explicitement decrits, notamment en relation avec les figures 2 
£ 15. 

En particulier, comme en ce qui concerne les autre agents intelligents 
traducteurs de script; la fonction de Pagent intelligent associ§ au systfeme de 
gestion de fichier virtuel peut etre remplie par un agent non d6di6 : Pagent 
"WEB" ou Pagent "APDU". 



36 



REVENDICATIONS 

1. Procede pour acceder a un objet localise dans un systeme 
informatique connecte a un reseau de type Internet par I'intermediaire d'un 
navigateur de type "WEB", ledit navigateur etant compris dans un terminal, 
muni d'un lecteur de carte a puce et connecte audit reseau de type Internet, 
caracterise en ce qu'il comprend au moins les phases suivantes : 

- a/ une premiere phase preliminaire consistant a implanter, dans ladite carte 
a puce (2a), une premiere piece de logiciel (23a), formant une couche 
protocolaire de communication specifique ; 

- b/ une deuxieme phase preliminaire consistant a implanter, dans ledit 
terminal (1), une seconde piece de logiciel (13), formant une couche 
protocolaire de communication specifique et formant interface avec au moins 
ledit navigateur "WEB" (10) ; 

- en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132,232a) cooperant Tune 
avec I'autre de maniere a permettre I'etablissement d'une session d'echanges 
de donnees bidirectionnels entre ledit terminal (1 ) et ladite carte a puce (2a), 
de maniere a ce que ladite carte a puce (2a) offre la fonctionnalite d'un serveur 
"WEB" ; 

- en ce qu'il est procede a une troisieme phase preliminaire consistant en 
I'implantation dans ladite carte a puce (2a) d'un systeme de gestion de fichiers 
dit virtuel (8), organise en repertoires (rep#0), sous-repertoires (srep#1, 
srep#2) et fichiers elementaires (fe#7, fe#5), une partie au moins desdits 
fichiers §lementaires etant constitues par des fichiers elementaires dits virtuels 
(fe#5), associes chacun a I'un desdits objets (Obvi) et contenant des donnees 
de description permettant au moins de localiser celui-ci et de generer des 
donnees constituant une methode d'acces ; 

- en ce qu'il comprend une quatrieme phase preliminaire consistant a 
implanter dans ladite carte a puce (2a) au moins une deuxieme entite logicielle 
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(7), apte a interpreter une suite d* instructions et a la traduire en une suite 
d'ordres, de maniere a cooperer avec ledit systeme de gestion de fichiers 
virtue! (8) et ladite seconde piece de logiciel specifique (23a) ; 
- et en ce qu'il comprend au moins les etapes suivantes : 

- 1/etablissement d'une session d'echanges de donnees entre ledit terminal 
(1) et ladite carte a puce (2a), par I'intermediaire d'une desdites paires de 
premieres entites logicielles appariees (132, 232ai), de maniere a transmettre 
une requete destinee a ladite deuxieme entity logicielle (7) cooperant avec 
ledit systeme de gestion de fichiers dit virtuel (8) ; 

- 2/ elaboration et transmission audit navigateur "WEB" (10), par 
I'intermediaire de ladite deuxieme entite logicielle (7), et via lesdites premiere 
(13) et seconde (23a) pieces de logiciel, d'une reponse a ladite requete 
comprenant une liste desdits objets (Obvi) accessibles via ladite carte a puce 

(2a); 

- 3/ selection par ledit navigateur "WEB" (10) d'un desdits objets accessibles 
et envoi a ladite deuxieme entite logicielle (7) d'une requete pour obtenir une 
instance de celui-ci dans ledit terminal ; 

- 41 generation par ladite entite logicielle (7) desdites donnees constituant une 
methode d'acces, en fonction desdites donnees de description ; et 

- 5/ recherche dudit objet (Obv/) par utilisation desdites donnees de 
localisation et de methode d'acces, et creation d'une instance de cet objet 
(Obvj) dans ledit terminal (1 ). 

2. Precede selon la revendication 1 , caracterise en ce que ledit lecteur de 
carte a puce (3) et ladite carte a puce (2a) comprennent des premiere et 
deuxieme piles protocolaires pour lesdites transmissions de donnees, definies 
par la norme ISO 7816, chacune comprenant au moins des couches 
protocolaires de communication logicielles (101, 200a), dites basses, de 
maniere a permettre lesdits echanges de donnees entre ladite carte a puce 
(2a) et ledit terminal (1), ces couches formant interface avec lesdites premiere 
(13) et seconde (23a) pieces de logiciel specifique formant lesdites couches 
protocolaires de communication specifiques, respectivement, et en ce que ces 
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pieces de logiciel (13, 23a) comprennent chacune deux entites 
supplementaires constitutes d'un module de transfer! de donnees (130, 230a), 
formant interface avec lesdites couches basses (101, 200a) des premiere et 
deuxieme piles protocolaires, et d'un module de gestion (131v231a), et en ce 
que lesdites premieres entites de chaque paire sont constitutes de modules 
logiciels, dits agents intelligents (132, 232a1) etablissant lesdites sessions. 

3. Procede selon la revendication 2, caracterise en ce que, ladite suite 
^instructions a interpreter etant constitute par un script, ladite deuxieme entitt 
logicielle (7) cooperant avec ledit systeme de gestion de fichiers virtuel (8) est 
constituee par un module logiciel dit agent intelligent traducteur de script 

4. Procede selon la revendication 3, caracterise en ce que ledit agent 
traducteur de script (7) cooperant avec ledit systeme de gestion de fichiers 
virtuel (8) est confondu avec ledit agent intelligent (232ai) etablissant lesdites 
sessions d'echanges de donnees entre ledit terminal (1) et ladite carte a puce 
(2a). 

5. Procede selon la revendication 3, caracterise en ce que lesdites 
applications sont d'un type devant etre active a I'aide d'un jeu d'ordres dits 
"ADPU", definis par la norme ISO 7816, ledit terminal (1) et ladite carte a 
puce (2a) comprennent une entite logicielle supplemental (102, 201a), dite 
gestionnaire d'ordres "ADPU", en ce que ladite interface entre lesdites couches 
basses (101, 200a) des premiere (101) et deuxieme (200a) piles protocolaires, 
d'une part, et lesdites premiere (13) et seconde (23a) pieces de logiciel 
specifique i (23a), d'autre - part, s'effectue par I'intermediaire desdits 
gestionnaires d'ordres ( 1 02, 200a). 

6. Procede selon la revendication 5, caracterist en ce queMedit gestionnaire 
d'ordres (201a) de la carte a puce (2a) comprend en outre une entite logicielle 
du type agent intelligent (2010a) permettant I'etablissement d'une session 
d'echanges de donnees bidirectionnels avec d'autres agents intelligents, cet 
agent (2010a) ttant dit agent intelligent gestionnaire d'ordres, et en ce que 
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ledit agent traducteur de script (7) cooperant avec ledit systeme de gestion de 
fichiers virtuel (8) est confondu avec ledit agent intelligent gestionnaire 
d'ordres (2010a). 

7. Precede selon la revendication 1, caracterise en ce que ladite deuxieme 
entite logicielle (7) cooperant avec ledit systeme de gestion de fichier virtuel (8) 
associe, a chacun desdits repertoires (rep#0), sous-repertoires (srep#1, 
srep#2) et fichiers elementaires (fe#7, fe#5), une adresse de type Internet dite 
"URL", en ce que ladite etape 21 de reponse consiste en I'envoi d'une page en 
langage "HTML" comprenant des hyperliens pointant sur lesdites adresses 
"URL", et en ce que ladite etape 3/ de selection consiste a actionner I'un de 
ces hyperliens de maniere a acceder a I'un desdits repertoires (rep#0), sous- 
repertoires (srep#1, srep#2) ou fichiers elementaires (fe#7, fe#5) ; I'acces a un 
repertoire (rep#0) ou a un sous-repertoire (srep#1, srep#2) occasionnant la 
transmission vers ledit navigateur "WEB" (10) d'une page en langage "HTML" 
presentant son contenu, et I'acces a un desdits fichiers elementaires virtuels 
(fe#5) occasionnant iadite recherche de I'objet (Obvi) associe a ce fichier 
elementaire virtuel (fe#5) et la creation d'une instance de cet objet (Obvi) dans 
ledit terminal (1). 

8. Precede selon la revendication 7, caracterise en ce qu'il est prevu au 
moins un agent intelligent traducteur de script supplementaire (232am. 232am) 
destine a I' interpretation d'un script predetermine, de maniere a remplir une 
tache predeterminee, et en ce qu'il comporte une premiere methode d'acces 
aux dits objets (Otow). dite directe, consistant a decrire lesdits agents 
intelligents supplementaires mis en oeuvre pour acceder aux dits objets (Obvy) 
et comprenant au moins les etapes suivantes : 

- a/ creation d'une structure d'appel comprenant au moins un element, chaque 
element comportant un identificateur d'un desdits agents intelligents 
supplementaires (232am, 232am) et des donnees, dites argument, utilisees par 
celui-ci pour I'execution de ladite tache ; 
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- b/ I'etablissement d'une session entre un premier agent intelligent 
supplemental (232a m ) et ledit agent intelligent (7) cooperant avec ledit 
systeme de gestion de fichier virtuel (8), cet agent intelligent supplemental 
(232a/j) etant selectionne par I'identifiant d'un premier element de ladite 
structure d'appel et retenant un element de ladite structure qui lui est destine ; 

- c/ lorsque ladite structure comporte plusieurs elements, etablissement d'une 
session entre ledit premier agent intelligent supplemental (232am). et un 
autre agent intelligent supplemental (232a n ), et transmission des elements 
restants de la structure d'appel, cet autre agent intelligent supplemental 
(232a/j) etant selectionne par ledit identifiant et retenant un element de ladite 
structure qui lui est destine ; et 

- 61 repetition de I'etape cl jusqu'a epuisement des elements constituant 
ladite structure d'appel. 

9. Precede selon la revendication 7, caracterise en ce qu'il comporte une 
seconde methode d'acces, dite indirecte, comprenant au moins une etape 
consistant,-en reponse a une <requete*transmise par ledit navigateur "WEB" 
(10) a ladite deuxieme entit6 logicielle (7) cooperant avec ledit systeme de 
gestion de fichier virtuel (8), designant un desdits fichiers elementaires virtuels 
(fe#5), a transmettre au navigateur "WEB" (10) une page en langage "HTML" 
(P) comportant un hyperlien pointant sur un enregistrement comportant des 
donnees n§cessaires a la generation de ladite methode d'acces. 

10. Procede selon la revendication 9, caracterise en ce que ladite page en 
langage "HTML" (P) comprend une piece de logiciel en langage "JAVA", 
chargee depuis ladite carte a puce (2a) ou depuis ledit reseau de type Internet 
(Rl), sous la commande dudit agent intelligent (7) cooperant avec ledit systeme 
de gestion de fichier virtuel (8), et executee par ledit navigateur "WEB" (10), de 
maniere a retrouver des donnees necessaire a la generation de ladite methode 
d'acces dans un fichier elementaire non virtuel dudit systeme de gestion de 
fichiers virtuel (8) ou par I'intermediaire d'une adresse contenue dans un 
desdits fichiers elementaires virtuels (fe#5). 
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11. Procede selon la revendication 9, caracterise en ce qu'il est prevu au 
moins un agent intelligent traducteur de script supplemental (232ap) destine 
a Interpretation d'un script predetermine, de maniere a remplir une tache 
predeterminee, en ce que ladite seconde methode d'acces indirect comprend 
au moins les etapes subsequentes suivantes consistant a decrire lesdits 
agents intelligents supplementaires mis en oeuvre pour acceder aux dits objets 
(Obvf): 

- a/ creation d'une structure d'appel comprenant au moins un element, chaque 
element comportant un identificateur d'un desdits agents intelligents 
supplementaires (232ap) et des donnees, dites argument, utilisees par celui-ci 
pour I'execution de ladite tache ; 

- b/ I'etablissement d'une session entre un premier agent intelligent 
supplementaire (232a p ) et ledit agent intelligent (7) cooperant avec ledit 
systeme de gestion de fichier virtuel (8), cet agent intelligent supplementaire 
(232ap) etant selectionne par I'identifiant d'un premier element de ladite 
structure d'appel et retenant un element de ladite structure qui lui est destine ; 

- c/ lorsque ladite structure comporte plusieurs elements, etablissement d'une 
session entre ledit premier agent intelligent supplementaire (232am). et un 
autre agent intelligent supplementaire (2Z2an), et transmission des elements 
restants de la structure d'appel, cet autre agent intelligent supplementaire 
(232an) etant selectionne par ledit identifiant et retenant un element de ladite 
structure qui lui est destine ; et 

- d/ repetition de I'etape cl jusqu'a epuisement des elements constituant 
ladite structure d'appel. 

12. Procede selon la revendication 10, caracteris6 en ce qu'il est prevu au 
moins un agent intelligent traducteur de script supplementaire (232ap) destine 
a I'interpretation d'un script determine, de maniere a remplir une tache 
predeterminee, en ce que ledit hyperlien definit I'adresse d'un premier agent 
intelligent traducteur de script supplementaire (232ap), et en ce que ladite 
seconde methode comprend au moins les etapes subsequentes suivantes 
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consistant a decrire lesdits agents intelligents supplementaires mis en oeuvre 
pour acceder aux dits objets (Obvj) : 

- a/ creation d'une structure d'appel comprenant.au moins un element, un 
chaque Element comportant un identificateur d'un desdits agents intelligents 
supplementaires (232ap) et des donnees, dites argument, utilises par celui-ci 
pour I'execution de ladite tache ; 

- b/ I'etablissement d'une session entre un premier agent intelligent 
supplementaire (232a p ) et ledit agent intelligent (7) cooperant avec ledit 
systeme de gestion de fichier virtuel (8), cet agent intelligent supplementaire 
(232a p ) etant selections par I'identifiant d'un premier element de ladite 
structure d'appel et retenant un element de ladite structure qui lui est destine ; 

- c/ lorsque ladite structure corhporte plusieeirs elements, "etablissement d'une 
session entre ledit premier agent intelligent supplementaire (2Z2a m ), et un 
autre agent intelligent supplementaire (232an), et transmission des elements 
restants de la structure d'appel, cet autre agent intelligent* supplementaire 
(232a n ) etant selectionn§ par ledit ideratifiant et retenant un element de ladite 
structure qui lui est destine ; et 

- 61 repetition de I'etape c/ jusqu'a epuisement des elements constituant 
ladite structure d'appel. 

13. Precede selon la revendication 3, en ce que ledit navigateur "WEB" (10) 
transmet a ladite carte a puce (2a), dans une phase preliminaire, une premiere 
serie de donnees de securite determinant des droits d'acces aux dits objets 
(Obvi) et en ce que ladite liste des objets (Obvi) accessibles via ladite carte a 
puce (2a) est 6tablie, sous la commande dudit agent intelligent traducteur de 
script (7) cooperant avec ledit systeme de gestion de fichier -virtuel (8), par 
comparaison avec une seconde serie- de donnees de securite* enregistrees 
dans une base de donnee de securite comprise dans ladite carte a puce (2a). 

14. Procede selon la revendication 13, caracterise en ce que ladite premiere 
serie de donnees de securite comprend un identifiant et un mot de passe. 
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15. Architecture pour la mise en ceuvre du procede selon la revendication 3, 
caracterisee en ce que : 

- - ledit terminal (1) comprend au moins ledit navigateur "WEB" (10), ladite 
premiere pile protocolaire (101), et ladite premiere piece de logiciel (13) 
constituant une couche protocolaire de communication specifique, formant 
interface entre ces couches basses (101) et ledit navigateur "WEB" (10) ; et 

- - ladite carte a puce (2a) comprend ladite deuxieme pile 
protocolaire (200a), ladite seconde piece de logiciel (23a) constituant une 
couche protocolaire de communication specifique, ledit systeme de gestion de 
fichiers virtuel (8) et ladite deuxieme entite logicielle constitute par un agent 
intelligent traducteur de script (7), cette derniere formant interface entre ledit 
systeme de gestion de fichiers virtuel (8) et ladite seconde piece de logiciel 
(23a). 

16. Architecture selon la revendication 15, caracterisee en ce que ledit 
systeme de gestion de fichiers virtuel est enregistre dans une memoire re- 
programmable (8) comprise dans ladite carte a puce (2a). 
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